-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esm: improve getFormatOfExtensionlessFile
perf.
#49965
esm: improve getFormatOfExtensionlessFile
perf.
#49965
Conversation
Review requested:
|
20d92eb
to
19caf5d
Compare
19caf5d
to
071f97f
Compare
071f97f
to
15bc0f1
Compare
|
||
const { closeSync, openSync, readSync } = require('fs'); | ||
const { getValidatedPath } = require('internal/fs/utils'); | ||
const pathModule = require('path'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We generally call this path
.
const pathModule = require('path'); | |
const path = require('path'); |
const path = pathModule.toNamespacedPath(getValidatedPath(url)); | ||
|
||
switch (fsBindings.getFormatOfExtensionlessFile(path)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const path = pathModule.toNamespacedPath(getValidatedPath(url)); | |
switch (fsBindings.getFormatOfExtensionlessFile(path)) { | |
const filePath = pathModule.toNamespacedPath(getValidatedPath(url)); | |
switch (fsBindings.getFormatOfExtensionlessFile(filePath)) { |
And break places that rely on patching the |
Would you mind adding those usages/packages to CITGM? I have no information regarding such usage. |
If virtual filesystems are a need then we should be explicit about such support. Patching is an unreliable approach. |
A significant amount of time and efforts has been put into it, but your CI is a little unstable at times, and having to ask a manual run after every workaround has added a lot of friction. Would be worth resurrecting, though. |
I'm all for that (it's something that's been discussed from time to time with loaders / customizations, or the SEA initiative), but until there is, I don't think it should be broken. Same thing as breaking the CJS patching, really. |
In many PRs (open and merged) sync FS ops are moving from using internal js funcs to being in pure C++ for more performance. Shouldn't this also be a concern with them if so or do VFS patches only care about async? |
Changing the internals of the public For example, if we make a |
Monkey-patching is not something that Node supports, and should be a minimal consideration (if any) as part of implementing Node features. If tools want customization hooks for filesystem operations, then put up PRs to create those hooks, along the lines of the module customization hooks API. We could even abstract the “run the hooks in a separate thread” stuff from the module customization hooks so that hooks for other systems also run in a separate thread, so that hooks can do async stuff within sync flows. I also disagree that it’s on the Node core team to create the hooks first and wait for the ecosystem to migrate, and support monkey-patching in the interim. We’ve never supported monkey-patching; it’s not part of our public API. We would be happy to support something official, a “filesystem customization hooks” similar to the module ones, if people want to put in the effort to create it. This should not impede performance improvements that will benefit everyone in the short term. |
I'm not really looking to discuss the fine frontier between "officially supported" vs "it just so happened to work for the past 10+ major releases". My point is simply that this change, as is, is breaking existing scenarios, period. It doesn't have to (as I mentioned the new fs primitive could be exposed somewhere), so I hope you can take that into consideration. |
Getting the format of a loaded module is already covered by the module customization hooks. If overriding the behavior of this new API is desired, it can already be done within the |
I agree we should try to avoid breaking existing cases, but the task should not be "do nothing" it should be to identify cases like that and reach out to come up with better solutions or direct them to using existing better solutions. Stability is important, but we also need to ensure we're not blocking ourselves from being able to make improvements in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the sentiment, happy for Node to provide hooks into APIs if interception is desirable.
As a long time project contributor/member it could be great if @arcanis can drive an effort to identify those requirements though I understand it if they don't have time.
#define EXTENSIONLESS_FORMAT_JAVASCRIPT (0) | ||
#define EXTENSIONLESS_FORMAT_WASM (1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT these are going to be exposed as enumerable properties of fs.constants
in userland?
Landed in 05be31d |
PR-URL: nodejs#49965 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: #49965 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
PR-URL: nodejs#49965 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Stephen Belanger <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Move
openSync
,readSync
andcloseSync
logic to C++ and return int for performance.cc @nodejs/performance we can use a similar approach to this pull request on other places in node.js core.